Systems and methods disclosed herein relate generally to tile-based mapping systems. The first web-based mapping systems offered rudimentary mapping applications through a web browser. A first type of system allowed simple map movements by requiring a user to click on navigation arrow buttons surrounding the map view. When a user clicked on an arrow, the map moved a predetermined amount in the direction clicked. There were also buttons for zooming in and out. Other map applications allowed users to drag and draw boxes on the map to relocate the map view. These applications had several disadvantages, including slow rendering and downloading of map views, because the map view was often represented by a single large image file. Each time the map was moved to the left or right, the entire image was re-rendered and re-sent to the client even though only a portion of the image was new. However, the interfaces were well suited to early web browsers, the map interface could be written entirely in HTML or with minimal JavaScript, and since all navigations were fixed, map servers could cache rendered maps. A second type of system adopted a map view and navigation style similar to desktop GIS systems which used browser plug-in technology and development platforms like Java or Flash.
GOOGLE MAPS® introduced the “slippy map” interface that allows users to move and zoom the map, and was written in HTML and JavaScript. A key technology behind the “slippy map” interface was the concept of tile-based mapping. Mapping applications were made responsive by using background maps that had been broken into smaller tiled images. Those tiles were stored, already rendered, on a central server. Because they were already rendered, they could be sent to clients quickly. The tiles were discretely addressed so they could be cached by internet caching services and by clients' own browsers. The map images were broken into smaller pieces so that when users navigated the map view, only the new parts of the map had to be resent from the server.
Tile-based mapping systems are based on multiple discrete zoom levels, each corresponding to a fixed map scale. In tile-based mapping systems, multiple image tiles are used to virtualize a single map view, and image tiles are accessible using a discrete addressing scheme. Also, in tile-based mapping systems, tiled images stored on a server system are sent to a client system with minimal processing, i.e. as much processing is done ahead of time as possible. Optionally, although not required in tile-based mapping systems, tile addressing can follow a single global projection, tiles can be distributed using a client/server system architecture, and tiles can be organized into relatively few, fixed layers. Tile images can be of any size, and can vary from map scale to map scale, or can vary across the same scale or be random in size. What is needed is a system to determine which size is most efficient for a specific purpose.
Referring now to FIG. 1A (PRIOR ART), tiled image sets are created from collections of random source images that may have sizes and boundaries that follow no specific system. Collections of source images can take a variety of forms, for example, high resolution aerial imagery of the fifty largest cities, each represented by a small number (for example 5-50) of large source images (for example 10,000×10,000 pixels). Each of the source images can be a different size, cover a different portion of the earth, or have a different map resolution. Taken together, all the source images for all the cities form a single map layer. Each layer 12 of tile images has multiple scales or levels 14. Every tile set starts with a base scale 221 which is the scale with the highest number and highest resolution imagery. Each subsequent scale is a lower version of the scale preceding it. In the tile creation process, base scale 221 (the highest resolution scale) can be completed before lower resolution scales. Scales 14 include tiles 18 that are addressable by columns 423. Referring now to FIG. 1B (PRIOR ART), exemplary base scale (level 3) 28 is the highest resolution scale in the exemplary series including level one 24 and level two 26, the lowest resolution level (scale) in the series. What is needed is a multi-processor, memory efficient system to create tiled images from source images.
Tiled images are divided into scales, and each scale is divided into rows and columns. The general problem of tile storage is to link a tile's address (layer, scale, row, and column) to a binary block of data. Tiled images can be stored in computer files on a computer-readable medium in a separate file for each tiled image, bundled together into larger files, or database tables. Storing many hundreds or thousands of tiled images in a single file can provide efficiencies that may not be available for other storage means. If the tiled images are written sequentially to a file, retrieval of individual images can be problematic without a way of knowing which tile address corresponds to which tiled image. Tile addresses can be stored with each image in the file, but in order to access a specific tiled image, the whole file is scanned, which could be inefficient. What is needed is a system for organizing blocks of data into scales, rows, and columns so that tiled images can be efficiently written to and read from a computer-readable medium.